上篇說，AI 功能多半不是死在模型不夠強，是死在沒有人定義「什麼叫對」。從今天起，我們用同一個虛構案例把判斷的順序走一遍：一座城市展館的導覽問答助手。設定、人物、數字全是教學假設——但每一步判斷都是真的。

助手翻車的第一現場

導覽助手上線了。遊客問「這件展品的背景」，它答得流暢自然，還會補充脈絡——常設展的資料它讀得很熟。

然後，颱風假前一天，館方發了臨時休館公告。有遊客問：「明天開嗎？」

助手用上個月的展覽資訊，給出了肯定的答案。

注意：它沒有當機、沒有報錯、甚至語氣還是那麼可信。它只是 在自己的能力邊界之外，安靜地失敗了 。而產品上線前，沒有人畫過這條邊界。

產品需要的不是排行榜，是任務能力圖

最直覺的反應是「換個更強的模型」。但這裡有個更早的問題：「更強」是對什麼而言？

Benchmark 榜單量的是模型在 別人題庫上的平均表現 。OpenAI 的評測指南說得很直接：公開 benchmark 衡量的是孤立能力，自建評測應該「忠實重現你自己的生產流量」。換句話說—— benchmark 是別人花園的天氣預報，不是你家的。 你的「氣候」由你的資料長相、問題類型、來源更新頻率決定。

所以我們要把「問答」拆開。看起來都是一問一答，其實是三種不同的能力：

1. 直接查詢：答案在某份文件裡，找出來說出來（展品背景）。
2. 跨文件比較：要在多份資料之間對照（「A 展和 B 展哪個適合帶小孩」）。
3. 缺資料判斷：答案不存在時，承認不存在（當日休館公告還沒進資料庫）。

第三種最容易被忽略，也最常出事。一篇歸納 RAG 系統失敗點的研究（Barnett 等，2024）把「資料缺漏時仍然作答」列為第一號失敗點——模型的天性是給出一個像樣的答案，而不是說「我不知道」。能力邊界畫不清楚的產品，等於把這個天性直接暴露給用戶。

怎麼畫：三題定一格

畫邊界不需要先蓋測試平台。Anthropic 的工程指南建議：從 20–50 個取自真實失敗的簡單任務開始，而且能力評測的初始通過率「本來就應該偏低」——第一版全是綠燈不是好消息，是題目太簡單。

落到操作，就三步：

1. 把問題分成三類：直接查詢、跨文件比較、資訊不足。
2. 每一類各寫三題，附上可接受的答案長相（不用完美，寫清楚「答對大概什麼樣」）。
3. 把結果記進一張表：可用／需人工／未知三格，每格標上資料日期。

展覽助手畫出來會長這樣（教學假設）：

那個「未知」格就是上篇說的「暫不開放」——能力邊界的第一個用途，是替 D1 的風險卡提供證據：不是我們保守，是這一格還沒有「可用」的證據。

反例檢查：有人會說「幹嘛這麼麻煩」

兩個常見反駁，正面回應。

「三個答案都對，就上啊」——這正是要拆的陷阱。 ihower 整理的 AI evals 辯論裡，一派確實主張：很多成功產品靠「感覺與 A/B 測試」就出貨了。這派不是錯，是有前提：錯誤後果低、且可以快速回滾。展覽助手答錯休館資訊，遊客白跑一趟——後果不可逆，所以這裡沒有「憑感覺」的豁免權。後果輕的格子，你當然可以直接上線觀察。

「驗證反正要上線後才準，事前畫圖有意義嗎」——同一篇 RAG 研究也說「驗證只有在營運中才可行」。但畫邊界不是要取代營運驗證，而是決定哪些格子敢放到營運裡驗證、哪些先關著。事前矩陣是閘門，不是保證。

補一個在地註腳：連正體中文的 benchmark（如 TMMLU+）也量不出「你的展館知識」——榜單飽和跟你的場景是兩回事。

我的立場

「模型很強」不是產品敘述，是行銷敘述。產品敘述長這樣：「這三類任務可用、這兩類轉人工、這一格還不知道」——每個字都帶著日期和證據。

本篇鍛鍊的思維習慣：以基準率校正預期、量化不確定（批判性思考）。

明天

能力邊界畫出來了，下一個問題更根本：這個需求，真的需要 AI 嗎？ 明天我們先替最笨的替代方案（一張靜態表格）辯護，再決定要不要讓模型上場。有時候最好的 AI 功能，是把 AI 拿掉。

如果你不想錯過這三十天的判斷練習，歡迎訂閱——我們明天見。

系列：AI 產品經理的決策修練：在不確定性下打造 AI 功能｜Day 2 of 30

參考：Anthropic — Demystifying evals for AI agents、Barnett et al. — Seven Failure Points in RAG Systems (2024)、ihower — AI Evals 大辯論、OpenAI — Evaluation best practices。文中展館與數字皆為教學假設。